Unsolicited Commercial E-mail, commonly known as “spam”, clogs mail servers and e-mail inboxes, costing an estimated $20 billion annually in 2003. Most existing solutions to prevent spam today are based on a content filter, which examines the text of an e-mail and uses a set of rules to determine if the recipient might want to receive it. This is an imperfect art which results in a race between spammers and filter maintainers. The result is unwanted spam passing the filter, and legitimate e-mail being incorrectly tagged as spam.
Another solution, commonly known as “challenge-response” is rarely used because of the large number of cases where it is unreasonable to expect a response to a challenge (mailing lists, legitimate mail from companies the recipient does business with, etc. An example of challenge-response is shown in U.S. Pat. No. 6,691,156 to Drummond et al., and assigned to IBM Corp. and incorporated herein by reference.
Another solution is provided by SPF, or “Sender Policy Framework”. SPF is a system for establishing that the identity of an e-mail sender is not spoofed. It works by allowing system administrators for a given domain to publish a record in DNS (an “SPF record”) which contains a list of hosts that are “authorized” to send mail from that domain. By looking up this record, the mail server on the receiving end can be sure of whether or not the client attempting to deliver mail is authorized to send mail from that domain.
SPF also has a “best guess” system, which is designed to help establish identity when an SPF record does not exist. The best guess system looks up all A and MX records for the e-mail address's domain, and compares the class C networks of the result with the class C of the client. It also compares the e-mail address's domain name with the client's domain name. The result of all the above tests is either a true, something matched—or false, nothing matched. Sender Policy Framework documentation is found at spf.pobox.com on the World Wide Web.
Another solution, “Caller ID for e-mail” is a MICROSOFT CORPORATION proposed system for verifying sender identity, and is part of MICROSOFT's “CSRI”, or Coordinated Spam Reduction Initiative. Domains which want their identity protected can add a record to DNS which mail servers can query to verify the sender's identity. Details about Caller ID for e-mail and CSRI are available at www.microsoft.com/mscorp/twc/privacy/spam_csri.mspx and in HTML format at 216.239.41.104/search?q=cache:iRHopkP-stQJ:spf.pobox.com/caller-id/csri.pdf+csri.pdf&hl=en and is incorporated herein by reference.
Also, a merged solution between SPF and CallerID for e-mail is being proposed.
DomainKeys is YAHOO CORPORATION proposed system for verifying sender identity. Domains which want their identity protected can post a public key to DNS, then sign all outgoing messages with a private key. Recipients can query DNS, retrieve the public key, and check the signature to verify the sender's identity. Details about it are available at antispam.yahoo.com/domainkeys and is incorporated herein by reference.
Other identity systems are being examined by MARID, or MTA Authorization Records in DNS, an IETF working group created to establish a standard for verifying sender identity. Details on MARID and the identity systems being considered can be found at www.ietf.org/html.charters/marid-charter.html.
Terminology:
                Simple Mail Transport Protocol (SMTP)—the standard used today to send mail across the internet. Most e-mail systems that send mail over the Internet use SMTP to send messages from one server to another; the messages can then be retrieved with an e-mail client using either POP or IMAP. In addition, SMTP is generally used to send messages from a mail client to a mail server. Defined in RFC 821 “Simple Mail Transfer Protocol” www.faqs.org/rfcs/rfc821.html by Information Sciences Institute University of Southern California incorporated herein by reference.        SMTP client—a computer which is sending mail across the internet using SMTP.        Mail Server—a computer which accepts connections from SMTP clients and receives e-mail messages for the recipient.        SMTP Transaction—defined as “mail transaction” and “SMTP mail transaction” in RFC 821.        Proxy server—a computer process that relays a protocol between client and server computer systems, by appearing to the client to be the server and appearing to the server to be the client.        SMTP Proxy—a computer process that relays the SMTP protocol (defined in RFC 821) between client and server computer systems.        Domain Name—a name for a computer or group of computers connected to the internet (i.e. example.com, or mail.example.com).        Hostname—A fully qualified Domain Name (FQDN) which represents a single computer connected to the internet i.e. “mail.example.com”.        Network Working Group Request for Comments: 1123 (RFC1123) defines and discusses the requirements for Internet host software. It can be found on the internet at “www.cse.ohio-state.edu/cgi-bin/rfc/rfc1123.html” and is incorporated herein by reference.        Domain Name System (DNS) is the standard used today to find IP addresses, mail servers, and other information for a domain name.         2LDN—second level domain name, i.e. example.com. Occasionally, in the context of this document, this actually has 3 levels, such as example.co.uk         Parent Domain—a higher level domain name. For example, mail.example.com is the parent domain of smtp.mail.example.com.        “A record”, “MX record”, “NS record”—Different records we can look up in DNS.        An IP address uniquely identifies a computer or network connected to the internet i.e. “192.168.0.34”.        A Class C address is a group of 256 IP addresses comprises the first three levels of the IP address, i.e. “192.168.0”.        
A Class B address is a group of 65,536 IP addresses comprises the first two levels of the IP address, i.e. “192.168”.                E-mail, or E-Mail Message—A message sent over the internet from a Sender to a Recipient, consisting of an Envelope and Content, as defined and used in RFC 822 “Standard for the format of ARPA Internet text messages” on the world wide web at www.faqs.org/rfcs/rfc822.html and incorporated herein by reference.        Envelope—Part of an e-mail message which contains whatever information is needed to accomplish transmission and delivery, as defined and used in RFC 822.        Content—Part of an e-mail message which is the object to be delivered to the recipient        Header—Part of the e-mail Content which provides information about the e-mail, i.e. Subject, as defined and used in RFC 822.         Body—Part of the message Content which contains the text of the message.        Envelope Sender—Part of the Envelope which specifies the e-mail address an e-mail would be returned to if it were not deliverable. Also known as the “bounce” address.        From address—A Header which specifies the e-mail address which most e-mail clients display, and which replies are generally sent to.        Reply-To address—A Header which specifies the optional e-mail address to which (when present) replies are sent. (This overrides the “from address” for replies, and is often used for mailing lists.)        